http://blog.gmane.org/gmane.ietf.smtp hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.smtp/9698 <pre>Hello everybody, this is a somewhat theoretical topic, but it seems to come up every few years in usenet discussions, so I'll ask for clarification/opinions. Consider this DNS configuration: A.example.com. CNAME M.example.com. M.example.com. MX 10 S.example.com. S.example.com. A 192.0.2.1 Now an MTA receives a message addressed to &lt;user&lt; at &gt;A.example.com&gt;. This MTA is a relay system and has no special configuration with regard to A.example.com. RFC 5321, section 5.1 specifies how to resolve "A.example.com", so by following the chain A.example.com -&gt; M.example.com -&gt; 192.0.2.1 the MTA will end up connecting to 192.0.2.1. We now have an SMTP connection and I will call this MTA the client and 192.0.2.1 the server. Which address should the client use in the RCPT TO command? 1) &lt;user&lt; at &gt;A.example.com&gt;, because a relay must pass on the message unmodified. 2) &lt;user&lt; at &gt;M.example.com&gt;, because M.example.com is the canonical name of the recipient domain. 3) Undefined behaviour. The MTA could even have rejected the message. 4) Other. If the client sends "RCPT TO:&lt;user&lt; at &gt;A.example.com&gt;", how should the server treat this? 1) Exactly the same as "RCPT TO:&lt;user&lt; at &gt;M.example.com&gt;", because A.example.com is an alias for M.example.com, so both must behave the same. 2) &lt;user&lt; at &gt;A.example.com&gt; and &lt;user&lt; at &gt;M.example.com&gt; may designate different mail boxes (and only one of them may exist). 3) Other. I do have an opinion and I think I can back it up with quotes from the RFC, but I've tried to state the question neutrally. hp </pre> Peter J. Holzer 2013-05-06T08:56:18 http://comments.gmane.org/gmane.ietf.smtp/9697 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> johnsonhammond2< at >hushmail.com 2013-04-27T16:52:14 http://comments.gmane.org/gmane.ietf.smtp/9696 <pre>Hi, Section 4.1.2 of RFC 5321 states the following ABNF production: Argument = Atom Strangely, I cannot find where this production is referenced or used. In the preceding obsoleted RFC2821, the situation seems identical and in RFC 821 that production didn't exist. So, what is this used for? Regards, Stephan. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Stephan Bosch 2013-04-23T23:10:37 http://comments.gmane.org/gmane.ietf.smtp/9681 <pre>GMail's submission server saves all the submitted mails to the sender's Sent mailbox. After this most IMAP clients with their default configuration will again save the same mail to the Sent mailbox. I'm not sure if GMail removes one of them as a duplicate or not. I've been considering doing a similar feature to Dovecot (it will most likely have a proxying submission server in near future), but it would be nice to tell the SMTP clients that this auto-saving is happening, so they could skip the IMAP APPEND part with default configuration. Of course there are the LEMONADE extensions that are supposed to solve this same issue, and Dovecot will support those as well, but I think it's going to take a while for clients to actually implement those. There's likely much better chance of them implementing a small check for "oh, the mail was already saved, I'll just skip the IMAP APPEND." Even if any clients themselves didn't implement this, it would make it possible to implement a simple SMTP+IMAP proxy locally that catches the flag and supresses the APPEND before it reaches the network. So, any thoughts on creating an RFC for this functionality? I'm not familiar enough with SMTP yet to know what would be the best design for that notification. Maybe a new extended status code? Maybe change some of the DATA reply's text part to have a special meaning? A simple flag is enough I think, because it's reasonable to require that both the server and client supports IMAP SPECIAL-USE to find the \Sent flagged mailbox. Returning IMAP UIDVALIDITY+UID could help IMAP clients a bit more, but that's maybe a bit too ugly (and not always possible). _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Timo Sirainen 2013-04-10T21:22:10 http://comments.gmane.org/gmane.ietf.smtp/9670 <pre>Hi, Once again I am faced with the question of what to do (as a "Dumb" SMTP client) when my outgoing interface has a private IP address and the name is locally administered. I checked RFC 5321 and can't get a *definitive* answer concerning whether or not a name like "Computer-Name.local" or "something.lan" is actually fully-qualified or not; certainly it is not *publicly* resolvable, but it is resolvable within the environment. My feeling is that it does not meet the definition of an FQDN. I cannot determine my name with only a private address, and my name is likely to be meaningless if I resolve it. So, what should I do when sending the HELO/EHLO command again? Is it worthwhile providing a "What is my name?" callback (that can be overridden) to try and automagically detect whether or not our name is likely to be meaningful based on domain suffix or IP address, and if not, use address literal? Or, given how some sites hate address literals, would it be easier and simpler to just churn out a completely useless "FQDN"? (I can't really see any convincing privacy argument in favour of one over the other, either.) Cheers, Sabahattin _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Sabahattin Gucukoglu 2013-03-26T16:17:21 http://comments.gmane.org/gmane.ietf.smtp/9667 <pre>Colleagues, (with apologies for the cross-posting if you get more than one copy of this) As you may have seen already, I'm working on a revision to RFC5451. A Proposed Standard "bis" effort always benefits from describing extant implementations. I know about the ones I've written, and about some very public uses of it (Gmail, Yahoo, for example). If there's anyone in this audience that knows of others, I'd love to hear about it. Reviews of the update are also welcome: https://datatracker.ietf.org/doc/draft-kucherawy-rfc5451bis/ Thanks, -MSK _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Murray S. Kucherawy 2013-03-22T17:01:00 http://comments.gmane.org/gmane.ietf.smtp/9666 <pre>More from Steve... ---------- Forwarded Message ---------- Date: Thursday, March 21, 2013 12:23 -0400 From: Steven Bellovin &lt;smb&lt; at &gt;cs.columbia.edu&gt; To: John C Klensin &lt;klensin&lt; at &gt;jck.com&gt; Subject: Re: [ietf-smtp] When using TLS, would randomizing the order of the EHLO response be helpful? One last word on the RC4 issue... See http://www.theregister.co.uk/2013/03/15/tls_broken/ and note this: "It's not a very practical attack in general, requiring at least 16,777,216 captured sessions, but as mentioned, attacks will only improve in time," said Arnold Yau, lead developer at mobile security firm Hoverkey. "I think it'd be wise for TLS deployments to migrate away from RC4 as advised." 2^24 sessions before a few bytes are readable, per http://www.isg.rhul.ac.uk/tls/ "Don't panic". ---------- End Forwarded Message ---------- _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> John C Klensin 2013-03-21T17:12:23 http://comments.gmane.org/gmane.ietf.smtp/9658 <pre>This is a question for folks that actually know crypto, and also know SMTP. A common theme of many of the recent statistical attacks on TLS (BEAST, Lucky 13, the ABPPS RC4 attack) has been knowing that some early part of the plaintext was constant. Knowing that some of the early bytes are limited to a range, or even fully known, was even more helpful. On every SMTP server in the world, the first 100 to 250 bytes send by the server after TLS negotiation completes are both constant and known: they're the EHLO response. So that got me wondering if randomizing the EHLO response could be helpful in mitigating statistical attacks. Obviously the degree of "randomizing" is limited; RFC 5321 requires the first line to be the FQDN of the receiver, and every line will contain "\r\n\220-". The most I can do is randomize whole lines. But I don't have an intuitive feel for what might be effective in disrupting these statistical code-breaking techniques; hence the question. I fully understand that fixing the vulnerabilities is much more important, but with RC4 in particular I'm wondering about hacks that might keep it a little more secure, a little bit longer. &lt;csg&gt; _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Carl S. Gutekunst 2013-03-21T07:47:00 http://comments.gmane.org/gmane.ietf.smtp/9595 <pre>Just an idea... maybe it's silly or not worth investigating, but I thought it wouldn't hurt to ask for comments. Thanks, Evert # Reject messages on backup mail exchangers when primary MX is online --- TODO: - Cascading? Like: test all MXs with lower preference number. - Check with [RFC 5321]. - Error messages: correct numbers? Ask for opinions. Negative replies can be permanent (5xx codes) or transient (4xx codes). - Discuss in newsgroup. - Test. - Write RFC. --- Author: Evert Mouw &lt;post&lt; at &gt;evert.net&gt; History: - 2013-02-06 first version ## Problem Multiple incoming mail servers (Mail eXchangers; MX) may be configured for a DNS domain. The MX with the highest priority, that is, the *lowest* preference number, MUST be contacted ([RFC 5321]) by the mailserver of another domain if that other mailserver wants to send mail. The MX with the lowest priority number is therefore called the *primary* MX. The other MXs are *backup* servers. The backup servers will be used by the sending party if the primary MX cannot be reached for whatever reason. In practice, reasons might, for example, be related to network configuration errors or hardware failure. Spammers have found that sending spam to both the primary MX and one or multiple backup MXs often works great to increase the number of spam messages being delivered. Often, backup MXs are less well configured to stop SPAM. Even if they are well configured, clever spam messages might be delivered by both the primary and the backup MXs, resulting in multiple spam messages for a receiver. Many mail administrators have responded by removing the backup MXs alltogether. The added costs of more spam, electricity and maintenance cost does not rationalize the availability of a backup MX. When the primary MX is offline, than the mails for the domain will be queued by the mailservers of the sending parties. This has major drawbacks. First, it places the costs of the storage and retries to the sending party while that party is not responsible for the downtime of the receiving mailserver. Second, when the primary MX is offline for too long, messages might be lost. Third, messages might be delayed for a long time, even after the primary MX did come back online. The proper way to address this issue is to deny the use of a backup MX when the primary MX is online. ## Bad solutions Some administrators run a periodic script (e.g. cronjob) on the backup MX to test if the primary MX is online (e.g. netcat to port 25 of the primary MX). If the primary MX is offline, they dynamically add a firewall rule to allow incoming port 25 traffic, or they start the SMTP daemon. Then the primary becomes online again, they block incoming 25 traffic and flush the queue and stop the SMTP daemon. This causes "mailserver unreachable" errors on legitimately configured mailservers when the primary MX is online but not reachable due to some network error on the side of the sender. It also is a bad solution for multiple-domain mail exchangers. ## One interesting solution An alternative implementation uses the ETRN command. The primary MX sends periodically an ETRN request to the backup MXs. The backup MXs will only become active when they did not receive such an ETRN request for a preconfigured period of time (e.g., 5 minutes). See the [hMailServer discussion]. ## Proposed solution On an incoming message, a backup MX should contact the primary MX to determine whether it is online (e.g., using HELO / EHLO). If it is online, then the backup MX should react with an error message 551, indicating that the sending party should try the primary MX first. SMTP Error 551 &lt;domain&gt; Try the primary MX first while it is online; please try &lt;primary MX&gt; If the sender continues trying such requests, then optionally the backup MX should periodically blacklist the sender, e.g. by rejecting it with an error message 550 571 indicating that the sender has too often tried to mis-use the backup MX. SMTP Error 550 5.7.1 You tried me, a backup MX, too often while the primary MX is online. Going even further, the offender could be placed on a public blacklist such as [SpamCop]. ## Gotcha's ### The preference debate There is a so-called [preference debate] on how a sender should react when the primary MX is not accepting mail of is offline. Some implementers interpret the RFCs as stating "immediately try a MX with a higher preference number, while others interpret it as "wait some time, and then try a MX with a higher preference number". Also, one could interpret it as "wait some time, and then try them all again, in order". Some mail servers will wait to try the backup MX for some time after not being able to deliver to the primary MX. So the following sequence could happen: 1. Sender tries to contact primary MX and fails; queues message. - Sender waits for some time. - Primary MX comes online again. - Sender tries backup MX. - Backup MX replies with 551 because the primary MX is back online. - Sender gives up. Of course, the sender should not give up. Some domains use [Nolisting] (Poor Man's Greylisting) and have a dummy primary MX. Although the claim is made that Nolisting is RFC compliant, I suggest that it is not in the spirit of the RFCs to list a false primary MX in the DNS *on purpose*. However, my proposal does not conflict with Nolisting because when the backup MX tests for connectivity with the primary MX, it will fail to connect and thus accept incoming mails. In practice, most MXs listed as backup MX in the Nolisting approach will behave as if they were a primary MX. --- [RFC 5321]: http://tools.ietf.org/html/rfc5321 [preference debate]: http://en.wikipedia.org/wiki/MX_record#The_preference_debate [SpamCop]: http://www.spamcop.net [Nolisting]: http://nolisting.org/ [hMailServer discussion]: http://www.hmailserver.com/forum/viewtopic.php?f=2&amp;t=19439 [RFC 2821]: http://www.ietf.org/rfc/rfc2821.txt _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Evert Mouw 2013-02-23T17:57:43 http://comments.gmane.org/gmane.ietf.smtp/9586 <pre>Does anyone here know of a legitimate MTA, proxy/filter, IDS, or similar critter that sends this verb before sending EHLO? FCCKV2 zQUdwkgzYhu/noMgcNtA0wvhrV0T9SThL3koEfk= I'm suspicious that it's a malware infection on the sender's host, but before I start making accusations I wanted to check around. Various web forums have also reported seeing this as an X-bar header line in HTTP requests, without identifying what it was. &lt;csg&gt; _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Carl S. Gutekunst 2012-09-28T21:26:48 http://comments.gmane.org/gmane.ietf.smtp/9584 <pre>The below should be of interest to members of these lists too. Tony. </pre> Tony Finch 2012-06-27T19:15:02 http://comments.gmane.org/gmane.ietf.smtp/9579 <pre>If this is not the right mailing list to ask my question, I apologize that. But I failed to find out any mailing list which is better than this. Configuring MUA, like Thunderbird, iMail or Outlook, is quite annoying for me because I have to know many configuration values; protocol, hostname, port, username, password, authentication method or more. If there is a protocol to negotiate the protocol to transport mails between mail client and server, based on preferences or capabilities of the both side, MUA could configure itself automatically without asking to user questions except mail address and password. For example, mail client asks to server(the domain part of the given mail address) which protocol it can use, and mail server replies that SMTP and IMAP is acceptable, and then mail client configures itself as server replies. Other configuration fields also could be filled in this way. Does anyone know a protocol such like that? _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> Yi EungJun 2012-06-21T16:25:38 http://comments.gmane.org/gmane.ietf.smtp/9578 <pre> A new IETF non-working group email list has been created. List address:ietf-smtp&lt; at &gt;ietf.org Archive: http://www.ietf.org/mail-archive/web/ietf-smtp/ To subscribe: https://www.ietf.org/mailman/listinfo/ietf-smtp Purpose: Discussion of issues related to Simple Mail Transfer Protocol (SMTP) [RFC 821, RFC 2821, RFC 5321] Notes: This replaces the existing ietf-smtp list hosted at imc.org, and subscriptions will be automatically transferred from that list to this. For additional information, please contact the list administrators. _______________________________________________ ietf-smtp mailing list ietf-smtp&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/ietf-smtp </pre> IETF Secretariat 2012-06-18T15:09:57 http://comments.gmane.org/gmane.ietf.smtp/9546 <pre> I have just submitted an I-D describing how to use DANE with SMTP. All comments welcome. Tony. </pre> Tony Finch 2012-05-25T17:15:36 http://comments.gmane.org/gmane.ietf.smtp/9529 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SMTP Service Extension for Greylisting Operations Author(s) : Hector Santos Evan Harris Filename : draft-santos-smtpgrey-02.txt Pages : 20 Date : 2012-04-27 GREYLIST is a SMTP extension to formalize the widely supported Greylisting mail filtering method and to help support SMTP rejected transports by following a new formal structured 4yz server temporary rejection response by including a "retry=time-delay" tag string which SMTP clients can use to optimize the rescheduling of the mail delivery attempts. With adoption, network overhead reduction in wasteful mail delivery attempts will be realized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-santos-smtpgrey-02.txt http://tools.ietf.org/html/draft-santos-smtpgrey-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-santos-smtpgrey-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-santos-smtpgrey/ </pre> Hector Santos 2012-04-27T23:10:22 http://comments.gmane.org/gmane.ietf.smtp/9528 <pre> Hi, I am going to be updating this I-D tonight to rev-02. I am wondering if there any implementations of the I-D. Its been six months since we implemented and its been 100% successful in minimizing mail send attempts to 2 and the minimizing the 2nd attempt delay to the greylisting server recommended wait time value. Thanks </pre> Hector Santos 2012-04-27T21:21:22 http://comments.gmane.org/gmane.ietf.smtp/9525 <pre> All, as you may know, an IETF working group is reviewing the SPF spec. The evaluation of current deployment is nearly completed, but thus far only analyzes published SPF records. Please contribute to a better understanding by completing the survey: https://www.surveymonkey.com/s/SPF-deployment-survey It will only take three minutes (ten questions on a single page). Please help reaching all mail admins by forwarding this prompt to specialized mailing lists and mail admins you are in touch with, worldwide. Thank you in advance! </pre> Alessandro Vesely 2012-04-27T06:07:33 http://comments.gmane.org/gmane.ietf.smtp/9524 <pre> Please comment on the apps-discuss list if you have any input. -----Original Message----- From: apps-discuss-bounces&lt; at &gt;ietf.org [mailto:apps-discuss-bounces&lt; at &gt;ietf.org] On Behalf Of Alexey Melnikov Sent: Tuesday, April 24, 2012 10:25 AM To: apps-discuss&lt; at &gt;ietf.org Subject: [apps-discuss] Call for Adoption: draft-kucherawy-received-state-02.txt Murray presented this draft in at least one of the face to face IETF meetings and my recollection is that general feedback on this document was positive. So I would like to initiate acceptance call for processing this document in the APPSAWG. Please indicate your support or objection, and opinions thereto before the close of business on May 1st. Alexey, as an APPSAWG co-chair _______________________________________________ apps-discuss mailing list apps-discuss&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss </pre> Murray S. Kucherawy 2012-04-24T17:44:43 http://comments.gmane.org/gmane.ietf.smtp/9442 <pre> Mails are allowed to have multiple addresses in the from header as long as they also have a sender header. However, in basic testing, I have yet to find a MUA that even displays multiple entries for from. Has anyone seen such a user agent? Functionally, should multiple from addresses be considered a deprecated feature? Thanks, Peter </pre> Peter Bowen 2012-02-27T18:35:38 http://comments.gmane.org/gmane.ietf.smtp/9425 <pre> Well, this is sad: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian &lt;http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html&gt; d/ </pre> Dave CROCKER 2012-02-18T23:07:25 http://comments.gmane.org/gmane.ietf.smtp/9423 <pre>Does anyone know of any MTAs that implemented the SUBMITTER extension, defined in RFC4405? -MSK </pre> Murray S. Kucherawy 2012-02-17T19:13:27 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.smtp